Complex software like applicant's SAP R/3 Release 4.5 (SAP) requires customization, e.g. selection of predefined functionality, and adaptation, e.g. addition of or amendment to functionality, as well as other servicing like program and data updates, cf. “SAP System Landscape Optimization” by A. Schneider-Neureither (Ed.), SAP Press, 2004, ISBN 1-59229-026-4, and “SAP R/3 Änderungs-und Transportmanagement” by Metzger and Röhrs, Galileo Press GmbH, Bonn, Germany, 4th reprint 2004, ISBN 3-934358-42-X.
Before such servicing may be performed, however, it has to be assured that the customizations, adaptations, program and data updates etc. are free of errors and integrate flawlessly into the software and data environment. In a factory for instance servicing errors are bound to result in costly workflow disruptions due to software malfunction or data corruption. Apart from the servicing side, other use of the software like training of new or inexperienced users may also result in a disruption of the productive system.
Such complex software may therefore be implemented in form of separate logical systems that together form a system landscape. A typical implementation of the aforementioned SAP software for instance may, cf. FIG. 1, comprise a development system 101 for customizing and development work, a quality assurance system 102 for testing functionality using representative test data, a training system 103 for training new users, and several productive systems 104, e.g. each for a different factory, for actual productive use. Other or additional users and systems may be defined according to the particular requirements.
The logical systems are identical in large parts, function autonomously and may be run on a single computer. The quality assurance system 102 for example resembles the productive system 104 in that it provides all the functionality, its present data and additionally special test data. New customization settings or adaptations may thus be thoroughly tested in the quality assurance system 102 without jeopardizing the productive system 104. Likewise, the training system 103 resembles the productive system 104 in that it provides some of the functionality and special test data. A new user using the training system 103 may thus become accustomed to the functionality and observe the effect of his actions, albeit without disturbing the productive system 104.
A transport management system connects the logical systems and serves to forward software services between systems of the system landscape via logical transport paths 105. A service may for example be approved in the development system 101 for export. It will then be forwarded to an input buffer of the quality assurance system 102. Import into the quality assurance system 102 is approved or denied manually by an operator. Thereafter, the software service is forwarded to the quality assurance system 102, and then to the training system 103 and the productive systems 104 where it will be imported following manual approval by an operator.
The operator is in charge of manually effecting the servicing. This requires an analysis of the system landscape layout, of the route that each service takes through the system landscape, project status switches in each system that define the respective system's changeability options, attributes in each service that define properties of the service etc. Import of services and other tasks are performed based on this analysis.
This process is time consuming and bears the risk of errors, in particular in cases that are not part of the routine servicing. In case of a malfunction of a productive system for instance a hot fix or program patch, here referred to as preliminary software service, needs to be implemented quickly. In such a case, only rudimentary testing of the preliminary software service in the development system may be regarded sufficient, so that the preliminary software service need not be imported into all systems but may be routed from the development system straight to the malfunctioning productive system. The operator then needs to analyze the system landscape, decide which systems to log into, which settings of which systems to change, etc.
Additionally, the preliminary software service needs to be transported through all systems in the next regular servicing. Otherwise it may become overwritten during the next regular service as illustrated by FIG. 2. An original version 201 of the software and data of the malfunctioning productive system 104 is first modified by a hot fix 202, resulting in modified version 203, and subsequently during regular servicing by a software service 204, resulting in modified version 205 with the hot fix 202 partially overwritten. The hot fix 203 therefore needs to be imported again after the regular service.
In view of the fact that an SAP R/3 implementation may comprise dozens of systems and require thousands of services per month during phases of change, the operator time required becomes considerable as does the risk for errors to occur.